The Delicate Art of Bureaucracy

🚀 The Book in 3 Sentences

This book dives into the concept of bureaucracy and why it exists. Afterwards, it dives into the three concepts of monkey (chaos tinkering), razor (slowly removing) and sumo wrestler (Using it against itself). These three methods are described in detail to show the reader how to deal with bureaucracy.

🎨 Impressions

The Al-Qaeda form application really got me. The Little Britain Computer Says no file.

I think this was a good book, and a must for all that works within digitalization and digital transformations.

✍️ My Top Quotes

Psychologists have watched children spend more time arguing over the rules of a game than actually playing
The three-page application to join al-Qa’ida asks applicants to list their hobbies and pastimes, and asks “What objectives would you like to accomplish on your jihad path?”
The Middle Ages saw Roman bureaucracy replaced by the feudal system, which (according to the economist and historian Ludwig Von Mises) was an attempt at governing without a centralized bureaucracy—an effort that failed miserably.
And it was the Holy Roman Emperor Charles V of Spain who, in modernizing the administration of his empire—yes, modernizing—gave us another useful term when he bound important documents with red tape instead of plain white string.
The term bureaucracy itself—“rule by offices” or “rule by desks”—was meant to be sarcastic when the French gave it to us in the mid-eighteenth century
Freedom has to be in tension with something, or it’s just randomness
Bureaucracy is a way to structure organizational interactions. That’s all.
The distinction I’ve laid out between traditional, charismatic, and rational-legal authority is more or less that of Max Weber
Impersonality is crucial to the bureaucratic mindset
“All complex organizations,” Wilson says, “display bureaucratic problems of confusion, red tape, and the avoidance of responsibility.”
One reason that businesses demand bureaucracy from the government is the predictability (calculability) it offers. Free markets require transparency and predictability:
What seems to underlie this type of speech is a denial of agency. Individuals avoid acknowledging their responsibility with the help of vague and confusing language, just as they do by pointing to bureaucratic rules they are obliged to follow.
As Arendt put it, bureaucracy was conveniently a system where “neither one nor the best, neither the few nor the many, can be held responsible, and which could be properly called the rule by Nobody…. Rule by Nobody is clearly the most tyrannical of all, since there is no one left who could even be asked to answer for what is being done.”
Scrum—please don’t hit me, Agile IT folks—Scrum is a bureaucratic way of performing IT delivery
But—I was told by my best bureaucracy savants—I could sign a Management Instruction, composed by them in fluent Orwellian, as long as it wasn’t a policy, and the people who worked for me would still have to follow it. This was becoming fun.
We have a leadership principle at Amazon that goes like this: Be Right a Lot. That helps when you’re taking risk in a bureaucracy as well: it’s less risky when you do the right things.
My bureaucratic variant on Occam’s Razor says “Don’t add extra work that doesn’t add value” or “Choose the process that is leanest, given an equal amount of value delivered” or, in the case where the value to the business is risk reduction, “Don’t do extra risk-reduction work that doesn’t reduce risk.” It’s a principle of bureaucratic parsimony.
Pigs and chickens: In Scrum, the project team members are “pigs” and everyone else is a “chicken.” The idea is that team members are fully committed, like pigs who provide bacon, and everyone else is only “involved,” like the chickens that provide eggs. Scrum says chickens should defer to pigs, as in George Orwell’s Animal Farm. Knowing Mr. Schwartz, he is probably also thinking of the fact that the pig-leader in Animal Farm is named Napoleon, one of Mr. Schwartz’s favorite historical figures.
From another angle, software code itself is a kind of bureaucracy. A rule-maker—called a programmer—writes code to represent rules that will be followed by the computer and the user, constraining the behavior of both.
The backlog, by the way, is a truly ingenious piece of bureaucracy—a last in, nothing out queue that imprisons requests until some inscrutable process grants them a hearing.
But as James C. Scott, a political scientist teaching at Yale, shows in Seeing Like a State, centralization results in a loss of important local details as higher-level abstractions are imposed.
Centralized government’s need to “make a society legible, to arrange the population in ways that simplified the classic state functions of taxation, conscription, and prevention of rebellion.”7 But such simplifications lose fidelity; the representation they create “always ignores essential features of any real, functioning social order.”
There are many good reasons why IT departments have inflicted ticketing systems†† on their colleagues, but there’s no denying that they’re a piece of IT bureaucracy that inspires our coworkers with dread and loathing.
According to von Mises, bureaucracy is necessarily inefficient, since it’s the system that’s used for management when there’s no market value for the services produced. Since nonprofits and government agencies can always spend more trying to deliver better service, their spending must be checked by rules and people who can say no—that is, a bureaucracy.
In “Bureaucracy and New Product Innovation,” James D. Hlavacek argues that because innovation always seems inefficient, it can have no place in a bureaucracy—which, as we know, is designed for efficiency (that idea again! Damn you, Max!).
In fact, bureaucracies are designed for precisely the opposite of innovation—they routinize what the company has done to make it repeatable.
Graeber says that “bureaucracy represents an inherent flaw in the democratic project.”19 “In principle,” he says, “all of these stuffy functionaries in their offices, with their elaborate chains of command, should have been mere feudal holdovers.”
In the British TV comedy Little Britain, a bank worker responds to every customer request by entering it into her computer and reporting “Computer says no!”
Once rules become rituals, changing them is tantamount to breaking apart the community. The rigidity with which rules are applied becomes a rigidity in the rules themselves.
Other studies indicate that employees don’t mind routinized processes as long as they’re designed well,
Division of accountability is also a core principle of DevOps, in that teams are fully committed and responsible for the IT capabilities they deliver. DevOps
DevOps principles say “run what you build.” The point—an important cultural difference from previous ways of doing IT—is that a team doesn’t toss its work over to someone else to manage when it claims to be “finished.”
DevOps is a model bureaucracy because it’s empowering while structured and controlled; lean as a matter of principle; and set up to learn through feedback loops and monitoring.
Joseph Clippinger III’s The Biology of Business to present the idea of businesses as complex adaptive systems (CASs). The idea of a CAS is based on biological systems that continuously adapt to survive natural selection. Managers in a CAS set up “fitness” parameters and then leave the business free to evolve, expecting that the processes most fit to deliver successful results will naturally survive.
Adler lists a set of conditions he believes are necessary for innovative behavior: a) a minimum of employment security b) a professional orientation toward the performance of duties c) established work groups that command the allegiance of their members d) the absence of basic conflict between work group and management e) organizational needs that are experienced as disturbing25
One of the characteristics of bureaucracy, as I’ve said, is that it’s self-documenting; that is, you not only comply but provide evidence that you have complied.
Virtually any complex task involving many variables whose values and interactions cannot be accurately forecast belongs to this genre: building a house, repairing a car, perfecting a new jet engine, surgically repairing a knee, or farming a plot of land. Where the interactions involve not just the material environment but social interaction as well—building and peopling new villages or cities, organizing a revolutionary seizure of power, or collectivizing agriculture—the mind boggles at the
1) difficult to make a mistake to begin with; (2) easy to identify a problem or know when a mistake was made; (3) easy in the normal course of doing the work to notify a supervisor of the mistake or problem; and (4) consistent in what would happen next, which is that the supervisor would quickly determine what to do about it.
This all took place within a traditional management hierarchy, well supplied with layers of middle management. Managers, however, were taught to view themselves as problem-solvers whose responsibility was to help the floor workers realize their process improvements. They were valued for their expertise, and it was through this expertise that they become managers. It was Weberian “domination through knowledge.”
Relation to their systems most systematisers are like a man who builds an enormous castle and lives in a shack close by; they do not live in their own enormous systematic buildings.
† This is the same IG that put the critical fact that he was comparing a twenty-year cost to a thirty-year cost into a footnote in his report, so take his testimony with more grains of salt than perhaps he has budgeted for. -au. In relation to their systems most systematisers are like a man who builds an enormous castle and lives in a shack close by; they do not live in their own enormous systematic buildings.
In relation to their systems most systematisers are like a man who builds an enormous castle and lives in a shack close by; they do not live in their own enormous systematic buildings.
For example, James Joyce, in writing Ulysses, famously said that he wanted to write a book from which a reader could reconstruct all of Dublin on June 14, 1906.
Writing the document forces the project teams to think ahead. But how valuable is that, really? Events they don’t plan for will still turn up by surprise; it’s impossible to foresee everything in such complex undertakings.
We’ll also describe our concepts for support and interoperability. (“We will support the software by fixing the bugs. The system will interoperate with our other systems.”
Tasks that will improve the metric. Studies of pay-for-performance medical programs, for example, note that they “can reward only what can be measured and attributed, a limitation that can lead to less holistic care and inappropriate concentration of the doctor’s gaze on what can be measured rather than what is important.”16 In “Don’t Let Metrics Undermine Your Business,” Harris and Tayler cite Wells Fargo’s debacle in which 3.5 million accounts were opened without the customers’ authorization. Wells was using a cross-selling metric to track its progress against a strategic objective of deepening relationships with customers. Unfortunately, the metric itself became the objective, and the company wound up accomplishing the opposite of the strategic goal that inspired it.17 When a window tax was instituted in England in 1696 and later in France during the revolution, the result was unfortunately predictable. The tax was intended to be progressive, based on an expectation
In practice, metrics result in gaming, perhaps through a hyperfocus on what is being measured to the exclusion of all else, or perhaps through creaming—the practice of only accepting tasks that will improve the metric.
The McNamara Fallacy is the mistake of making decisions based only on quantitative factors and ignoring all others. It was identified by Robert McNamara, the US Secretary of Defense, during the Kennedy and Johnson administrations, and refers to mistakes he and his fellow “best and brightest”¶¶ advisors made during the war in Vietnam, particularly declaring that the war was going well based on the count of dead bodies (“body bags”) rather than considering less tangible factors like strategy, leadership, group cohesion, morale, and motivation.
Goodhart’s Law, named for economist Charles Goodhart, tells us that when a measure becomes a target it stops being a good measure. His original framing was that “any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes
Newton’s Flaming Laser Sword, also known as Alder’s Razor, is the principle that what cannot be settled by experiment is not worth debating. It’s a principle of parsimony, like Occam’s Razor, but it shears away any ideas whose effects are not observable and measurable.
What we can call Scott’s Law, introduced in Seeing Like a State, is a variant on the streetlight effect: it’s his observation that there is a “strong incentive to prefer precise and standardizable measures to highly accurate ones.”
Gresham’s Law, named for Sir Thomas Gresham, a sixteenth-century financier, is an economic principle that bad money tends to drive out good money. James Q. Wilson gives us a variant that he says applies to many government bureaus: “Work that produces measurable outcomes tends to drive out work that produces unmeasurable outcomes.”
The most important thing I have to teach you is the importance of banging your head against the wall, repeatedly, until the wall starts to move. It worked for me.
The Monkey probes and provokes, learns how the organization really works—its politics, dynamics, people’s hidden motivations—then uses those learnings as a lever to move the unmovable. The Monkey does so with good humor and a light touch
He’s the iconoclast who questions what’s obviously true, just because it is obviously true.
As Kafka implies, bureaucracy in a large enterprise is complex, nuanced, and self-healing. If you change something, it adjusts and restabilizes in a new obstructionist way.
There’s a reason for each bit of bureaucracy. It’s not always a good reason, but the Monkey can sniff it out.
First, we made sure that employees saw themselves as professionals, with a responsibility to their craft. We maintained a library of technical books in the office, brought guest speakers, conducted “safaris” where we’d visit companies to learn from their IT people, sent employees to training, and, probably most impactful, sent them out to speak at events about the innovative things we were doing. As they became more sophisticated in their knowledge of cutting-edge techniques, it was natural for them to resist the stale bureaucratic rules that had been carved in silicon in the days when it was a good practice to keep hitting the reset button on your computer and stacking your punch cards neatly. Second, we coached employees on how to reconcile our new techniques with the rules, or in finding ways to get the rules changed. They were often already in the best position to know how to do it. It was my bureaucracy-savant employees who found the right medium in which to cast our own bureaucratic artworks—I would never have thought of declaring a Management Instruction without their help. It was our project managers, well experienced in doing ineffective procurements, who could teach us what we had to change in the procurement rules.
And third, we promoted our successes far and wide. By showing employees that we were actually getting somewhere in bringing new ideas into the bureaucracy, we reduced their feeling of helplessness, one shoulder-shrug at a time.
Each passing day destroys business value, as capital is not being put to use to earn that return.
For example, if we need a change to one of our IT systems because of a terrorist incident and that change is being held up by minimal-value signature hunting, let’s frankly confront an official and say, “Are you comfortable that you’re risking having more people die because you’re making this take longer?”
Red tape is an impediment. Whose job is it to remove the impediment? Yours and mine.
Although Agile IT discourages the use of command-and-control authority in favor of collaborative networks and empowered teams, I found that using it to remove impediments for a team was another matter. They usually didn’t object to it.
At Amazon, on the other hand, we use a principle of “escalate quickly.” It reinforces the culture of leanness and urgency. I wanted my teams to believe that passively accepting an impediment and allowing it to cause delays was not okay. But,
At Amazon, on the other hand, we use a principle of “escalate quickly.” It reinforces the culture of leanness and urgency. I wanted my teams to believe that passively accepting an impediment and allowing it to cause delays was not okay.
The monkey wants to find out “How can I?” never assuming that he can’t. The answer is different in each organization and with each piece of bureaucratic apparatus. He asks questions like these: What can I do that will help me learn how to get things done? How can I get the overseers to have skin in the game? How can I use my personal relationships? What’s the critical impediment right now? What can I do to overcome it? How can I make people understand the cost of delay?
Drawing on my fine command of the English language, I said nothing. —Robert Benchley
Advanced razor tip: Add up the time spent doing versus time spent watching as I discussed in Chapter 9. This is an advanced tip because it can make people feel threatened. Don’t cheat by only including the IT department. Doing includes things like writing code, testing, deploying, and engineering infrastructure. Watching includes things like project management, status meetings, management, writing (certain) documents, getting sign-offs, governance processes, compliance specialists, CMMI experts … probably most of your costs.
Rework: Because no-sayers and reviewers arrive late in a process and their job is not to improve the work but to return it for changes, rework tends to be maximized. If the pharaoh reviews the pyramid after it’s built and decides that he doesn’t like the view from his tomb—or wants more room for his harem in the next life—then the slaves will have a lot of rework ahead of them.
Overspecification: You know the story of the $3,000 military coffee pot from Chapter 1. If you write specifications for a product before you know how much each requirement will add to the cost, then you’re making decisions with incomplete information, and it will cost you. This often happens with requirements given to an IT organization—somewhere embedded in those requirements is a feature that is enormously but not obviously expensive—only IT will know it, upon deeper analysis, but not the requestor.
The commentators tell us: the correct understanding of a matter and misunderstanding the matter are not mutually exclusive. —Franz Kafka, The Trial
Like to fight, so they “play it safe” by conservatively interpreting the rules or setting even stricter rules for themselves … just to be sure. That’s why we were told that we weren’t allowed to sign time and materials contracts because “they were frowned upon,” and that there had to be parity between paper and electronic forms.
We learned to ask, first, where a rule came from—“Is that your rule or is it required by some law or policy?” The answer was almost always “No, it’s not my rule, it’s the law.” The second question was: “Can you point me to exactly where it says that in the law or policy?” In many cases, we found, the law said something different, if it existed at all.
And I’ll say it again—those conservative interpretations have a cost. The way of the Monkey is to expose the waste. The way of the Razor is to cut it away. And the way of the Sumo Wrestler is to gain and use leverage by questioning the enforcers and examining the rules more closely.
We asked our bureaucratic overseers: What would make your job easier? We treated them as the customer of our new and improved oversight process. We took in their feedback frequently and adjusted our process. They hadn’t fully realized how much of a burden the old oversight process was on them, with its long and wordy documents and its drawn-out review meetings.
Ask yourself: If employees were given the choice, would they use your bureaucratic mechanisms? If they simplify or speed up a repetitious task, probably yes. If they needlessly constrain the employee, the initial answer is probably no.